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Abstract 

Some  of  the  most  promising  work  in  the  area  of 
enforcing  secure  information  flow  in  programs  is 
based  on  static  analyses  of  source  code.  However, 
as  yet,  these  efforts  have  not  had  much  impact  in 
practice.  We  present  a  new  approach  to  analyz¬ 
ing  programs  statically  for  secrecy  and  integrity 
flow  violations.  The  analysis  is  characterized  as  a 
form  of  type  inference  in  a  secure  flow  type  sys¬ 
tem.  The  type  system  provides  a  uniform  frame¬ 
work  for  traditional  type  checking  of  programs  and 
information  flow  control.  Type-correct  programs 
have  principal  types  that  characterize  how  they 
can  be  called  securely.  Applications  of  the  type 
system  include  flow  analysis  of  legacy  code  as  well 
as  code  written  in  newly-emerging  Web  languages 
like  Java(tm). 

Keywords:  secure  information  flow,  certification, 
type  systems,  Web  programming 

1  Introduction 

Secure  information  flow  within  systems  having 
multiple  sensitivity  levels  has  long  been  a  widely- 
recognized  problem.  The  classical  problem  is  that 
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of  a  multilevel  subject,  one  with  a  range  of  security 
classes,  executing  code  that  either  accidentally  or 
maliciously  leaks  or  corrupts  sensitive  data.  Leak¬ 
ing  such  data  is  a  violation  of  secrecy  while  its 
corruption  is  a  violation  of  integrity  [5,  10].  Early 
work  in  the  area  was  motivated  by  the  need  to 
securely  handle  information  classified  at  different 
levels  within  the  government,  the  military  in  par¬ 
ticular.  But  the  problem  is  now  also  apparent 
within  the  context  of  Internet  programming  and 
newly-emerging  Web  programming  languages  like 
Java  [14]. 

With  Java,  programs,  called  Java  applets^ tm), 
can  be  downloaded  from  the  Internet  and  executed 
with  user  privileges  by  a  JaM-compatible  Web 
browser  like  HotJava( tm)  or  Netscape  Navigator 
2.0.  There  are  obvious  secrecy  and  integrity  prob¬ 
lems  here.  For  instance  a  downloaded  applet  may 
attempt  to  make  the  contents  of  a  user’s  private 
Hies,  such  as  mailfolders  or  log  files,  public  by  mail¬ 
ing  them  to  remote  sites.  Currently,  users  have 
the  option,  as  in  Hot  Java,  to  forbid  downloaded 
code  from  accessing  any  local  files.  This  is  called 
the  Applet  Host  mode.  In  fact,  this  is  the  only 
“security  mode”  available  in  the  Netscape  Naviga¬ 
tor  beta  release.  But  such  steps  will  undoubtedly 
prove  to  be  too  impractical.  Useful  applets,  like 
mail  and  other  transaction  tools,  will  need  access 
to  private  files  in  order  to  perform  their  tasks. 

This  is  where  the  static  analysis  of  code  for  se¬ 
cure  information  flow  can  provide  a  finer  level  of 
security  in  terms  of  secrecy  as  well  as  integrity. 
For  instance,  it  can  allow  access  to  private  files 
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yet  guarantee  that  their  contents  are  not  stored 
in  public  places.  We  begin  by  examining  some  of 
these  analyses  in  the  next  section.  Unfortunately, 
they  have  had  little  impact  in  practice.  In  Sec¬ 
tion  3,  we  propose  an  alternative  form  of  static 
analysis  based  on  a  powerful,  yet  very  practical, 
notion  called  type  inference. 

2  Information  Flow  Control 
Strategies 

Secure  information  flow  within  systems  was  stud¬ 
ied  years  ago  by  Bell  and  LaPadula  [4,  3].  This  was 
followed  by  the  work  of  Denning  who  presented  a 
lattice  model  of  secure  information  flow  certifica¬ 
tion  and  gave  an  algorithm  for  analyzing  programs 
for  secure  implicit  and  explicit  flows  [6,  7,  8].  Den¬ 
ning  provided  an  informal  treatment  of  the  sound¬ 
ness  of  secure  flow  certification.  A  more  formal 
treatment  of  its  soundness  was  given  by  Mizuno 
and  Schmidt  [12],  which  is  discussed  in  [15]. 

Andrews  and  Reitman  [1],  in  a  related  effort, 
proposed  extending  a  traditional  axiomatic  logic 
for  program  correctness  with  secure  flow  certifica¬ 
tion.  Their  emphasis  was  on  a  formal  specifica¬ 
tion  of  certification  in  a  programming  logic.  They 
did  not  consider  any  practical  algorithms  for  their 
extended  logic,  nor  was  soundness  of  the  logic  ad¬ 
dressed.  These  are  major  drawbacks  of  their  work. 

The  more  recent  work  of  Banatre,  Bryce,  and  Le 
Metayer  [2]  is  based  on  statically  detecting  flow  vi¬ 
olations  from  an  accessibility  graph  constructed  for 
a  program.  These  graphs  record  information  flows 
among  variables  at  certain  program  points.  This 
work  and  secure  flow  certification  are  discussed  in 
more  detail  in  the  next  two  sections. 

2.1  Denning’s  Secure  Flow  Certifi¬ 
cation 

In  the  lattice  model  of  secure  flow  certification, 
a  flow  policy  is  represented  by  a  poset  <  S,  —>■> 
where  S  is  a  set  of  security  classes  and  — >■  is  a 
partial  order,  called  the  flow  relation,  specifying 
permissible  flows  between  classes.  Every  variable 


x  is  assigned  a  security  class  denoted  by  x  and  it 
is  assumed  that  x_  is  static  and  can  be  determined 
from  class  declarations  given  in  a  program.  If  x 
and  y  are  variables  and  there  is  a  flow  of  informa¬ 
tion  from  x  to  y  then  it  is  a  permissible  flow  iff 
x—>y. 

Every  programming  construct  has  a  certification 
rule.  Some  rules  certify  explicit  flows  while  others 
certify  implicit  flows.  For  example,  an  assignment 
statement  y  :=  x  is  certified  iff  x  —>■  y,  that  is,  the 
flow  of  information  from  the  security  class  of  x  to 
that  of  y  is  prescribed  by  the  flow  relation.  This 
is  an  example  of  certifying  an  explicit  flow.  The 
rules  for  conditional  constructs,  such  as  if  state¬ 
ments  and  while  loops  certify  implicit  flows.  For 
example,  the  conditional  statement 

if  x  =  0  then  y  :=  0  else  z  :=  0 

is  certified  iff  x  —>■  y  and  x^z_. 

If  the  poset  <  S,  —>■>  is  a  lattice,  so  that  for 
any  pair  of  classes  there  are  unique  upper  and 
lower  bound  classes,  then  a  simple  attribute  gram¬ 
mar  can  be  given  to  certify  programs.  It  con¬ 
sists  only  of  synthesized  attributes  which  are  se¬ 
curity  classes  computed  using  least  upper  bound 
(®)  and  greatest  lower  bound  (®)  operators  [8]. 
For  instance,  the  certification  condition  for  the  if 
statement  above  would  become  the  single  condi¬ 
tion  x_  —>■  y  (g)  z . 

2.1.1  Limitations  of  Certification 

One  drawback  of  Denning’s  flow  certification  is 
that  it  requires  security  classes  of  variables  to  be 
known  at  certification  time.  So  it  is  unsuitable  for 
analyzing  legacy  code  unless  the  code  is  prepro¬ 
cessed  to  include  appropriate  security  class  decla¬ 
rations  for  all  program  objects. 

Another,  perhaps  more  serious  practical  draw¬ 
back,  is  its  treatment  of  procedures.  Procedure 
calls,  in  flow  certification,  have  the  form 

call  q  (ai,  .  .  . ,  am;  b1;  .  .  .  ,bn) 

where  the  actual  input  parameters  are  a\,  .  .  . ,  am 
and  the  actual  output  parameters  are  bi,  ...  ,bn. 
If  procedure  q  has  formal  input  parame¬ 
ters  xi,...,xm  and  formal  output  parameters 
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yi,  .  .  .  ,yn,  then  the  security  of  the  call  requires 
that  three  conditions  be  verified: 

(a)  q  is  secure, 

(b)  cii  —>■  X{  for  i  =  1,  .  .  . ,  m,  and 

(c)  Vj_  for  j  =  1)  •  • 

Conditions  ( b )  and  (c)  certify  flow  into  and  out 
of  the  procedure  respectively.  Notice  that  q  can 
output  results  of  a  higher  class  than  the  inputs. 
For  example,  suppose  S  consists  of  security  classes 
L  (low)  and  H  (high),  with  L  —>■  H,  and  consider 

procedure  copy  (in  x  :  mt  L,  out  y  :  mt  H) 
y  :=  x 

end 

Procedure  copy  copies  its  input  x,  declared  with 
security  class  L,  to  its  output  y  of  class  H . 

We  can  imagine  erasing  the  class  declarations 
from  the  procedure  so  that  it  could  be  called  to 
copy  from  H  to  H  or  from  L  to  L,  giving  us  a  form 
of  polymorphism  with  respect  to  classes.  To  certify 
calls  of  procedures  that  are  generic  with  respect  to 
security  classes,  Denning  proposes  replacing  con¬ 
ditions  ( b )  and  (c)  by  the  single  condition 

(&')  ai  0  •  •  •  0  am  —>  bi  (g)  •  •  •  (g)  bn 

under  the  assumptions  that 

1.  procedure  q’ s  output  parameters  are  derived 
solely  from  the  input  parameters  and  informa¬ 
tion  in  a  least  class, 

2.  any  local  variables  of  q  are  erased  upon  return, 
and 

3.  q  does  not  write  into  any  nonlocal  objects. 

Notice  that  (&'),  unlike  ( b )  and  (c),  does  not  men¬ 
tion  the  formal  parameters  of  q,  only  the  actual 
parameters  of  a  call.  Thus  different  calls  to  q  can 
induce  different  instances  of  (&'),  so  polymorphism 
is  achieved  but  at  a  very  high  cost.  Assumptions 
1-3  are  too  restrictive  in  practice.  Useful  proce¬ 
dures  like  a  monitor  for  controlling  access  to  a 
shared  buffer  are  prohibited.  Also  compilers  nor¬ 
mally  make  no  attempt  to  erase  the  value  of  a  local 


variable  on  the  stack.  Besides,  these  assumptions 
still  have  to  be  verified  before  (&')  can  be  used 
which  is  clearly  outside  the  realm  of  certification. 

Mizuno  proposed  a  more  flexible  strategy  for 
certifying  recursive  procedures  in  the  style  of  Den¬ 
ning  [11].  It  involves  generating  flow  constraints 
for  a  program  by  computing  the  least  fixed  point 
of  a  set  of  symbolic  flow  equations.  The  equations 
are  constructed  according  to  Denning’s  certifica¬ 
tion  rules.  The  strategy,  though,  is  limited  to  pro¬ 
cedures  whose  arguments  are  passed  by  value  or 
by  result. 

2.2  Banatre  et  al’s  Information 
Flow  Detection 

Banatre,  Bryce,  and  Le  Metayer  give  a  compile¬ 
time  algorithm  for  detecting  information  flow  in 
sequential  programs  whereby  variables  need  not  be 
annotated  with  security  classes  [2].  What  makes 
their  work  appealing  is  that  the  algorithm  is  de¬ 
rived,  through  a  sequence  of  steps,  from  an  initial 
axiomatic,  information-flow  logic.  The  result  is 
an  inference  system  whose  rules  are  used  to  trans¬ 
form  information  flow  graphs,  called  accessibility 
graphs.  The  result  of  applying  these  transforma¬ 
tions  to  an  initial  graph  for  a  given  program  is 
a  final  accessibility  graph  indicating  whether  the 
contents  of  one  variable  at  some  point  in  the  pro¬ 
gram  can  flow  into  an  instance  of  a  variable  at 
some  other  point.  The  drawback  here  is  that  the 
number  of  vertices  in  the  final  accessibility  graph  is 
at  least  linear  in  the  size  of  the  program’s  abstract 
syntax  tree.  This  means  that  final  graphs  are  ex¬ 
tremely  sensitive  to  program  size  as  we  shall  see  in 
Section  3.1.  Thus  they  are  unsuitable  as  specifica¬ 
tions  of  the  secure  flow  properties  of  programs. 

3  Secure  Flow  Typing 

Type  systems  have  been  used  to  capture  a  variety 
of  different  kinds  of  program  analyses.  A  type  sys¬ 
tem  is  basically  a  set  of  inference  rules  with  which 
one  infers  various  properties  of  programs.  Secure 
information  flow  is  a  program  property,  so  we  can 
characterize  it  as  a  type  correctness  issue. 
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The  secure  flow  type  system  overcomes  the  lim¬ 
itations  of  flow  certification  mentioned  above  and 
does  not  require  calculation  of  least  fixed  points  as 
in  Mizuno’s  approach.  It  is  a  uniform  framework 
for  traditional  type  checking  in  programming  lan¬ 
guages  and  secure  flow  enforcement.  That  is,  the 
issue  of  secure  flows  is  no  longer  orthogonal  to  the 
more  traditional  type  correctness  issue  of  whether 
a  program  is  well  formed.  Further,  standard  type 
inference  techniques  can  be  used  to  automate  se¬ 
cure  flow  analysis  in  a  way  that  makes  it  more 
practical. 

In  the  secure  flow  type  system,  security  classes 
are  basic  types,  which  we  denote  here  by  r,  and 
the  typing  rules  enforce  secure  information  flow. 
For  example,  consider  the  typing  rule  for  an  as¬ 
signment  statement  x  :=  e: 

7  b  x  :  t  acc,  7  b  e  :  r  (1) 

7  h  x  :=  e  :  t  cmd 

In  order  for  the  assignment  to  be  well  typed,  it 
must  be  that 

•  x  is  a  variable  of  type  r  aee(eptor),  meaning 
x  is  capable  of  storing  information  at  security 
level  r,  and 

•  expression  e  has  type  (security  class)  r. 

Information  about  x  is  provided  by  7  which  maps 
identifiers  to  types.  So,  the  rule  states  that  in  order 
for  the  assignment  x  :=  e  to  be  judged  secure,  x 
must  be  a  variable  that  stores  information  at  the 
same  security  level  as  e.  If  this  is  true,  then  the 
rule  allows  us  to  ascribe  type  r  cmd  to  the  entire 
assignment  statement.  In  general,  a  statement  has 
type  r  cmd  only  if  every  variable  assigned  to  in 
the  statement  is  capable  of  storing  information  at 
security  level  r  or  higher.  Note  that  Denning’s  flow 
certification  would  not  be  concerned  with  whether 
x  of  x  :=  e  is  a  variable  or  a  constant.  But  this  is 
not  true  of  rule  (1),  which  addresses  the  issue  of 
well  formedness  as  well  as  secure  flow. 

Another  novel  aspect  of  the  type  system  is  its 
use  of  subtyping.  A  flow  policy  <  S,  —>■>  naturally 
corresponds  to  a  subtype  relation.  If  si  and  s 2  are 
members  of  S,  or  in  other  words  are  basic  types, 


such  that  si  —>■  s 2,  then  we  say  si  is  a  subtype  of 
s 2,  written  si  C  s2. 

Notice  that  typing  rule  (1)  requires  x  and  e  to 
have  the  same  security  level.  This  might  appear 
too  restrictive  for  the  rule  prevents  an  upward  flow 
from  e  to  x,  say  for  example,  if  x  were  high  and  e 
low.  This  is  where  subtyping  comes  into  play.  It 
allows  us  to  coerce  the  type  of  e  from  low  to  high 
to  get  agreement.  A  detailed  formal  treatment  of 
all  typing  rules  and  the  subtyping  logic  is  outside 
the  scope  of  this  paper  and  can  be  found  instead 
in  [15]. 

3.1  Polymorphism  and  Type  Infer¬ 
ence 

A  major  advantage  of  the  secure  flow  type  system 
is  that  it  can  be  implemented  using  powerful  type 
inference  techniques.  A  type  inference  algorithm 
not  only  proves  whether  a  procedure  is  typable,  or 
free  of  illegal  flows,  but  it  also  produces  a  principal 
type,  which  characterizes  how  the  procedure  can  be 
called  securely. 

A  principal  type  usually  comprises  a  set  of  sub- 
type  constraints  among  security  classes,  each  of  the 
form  7”i  C  T2.  Subtype  constraints  may  be  generic 
and  involve  type  variables  that  range  over  all  secu¬ 
rity  classes.  These  variables  can  be  specialized  in 
many  different  ways,  depending  on  the  procedure’s 
calling  context.  A  context  will  require  them  to  be 
specialized  in  a  certain  way.  As  long  as  the  spe¬ 
cialization  satisfies  the  constraints,  the  procedure 
can  be  executed  without  causing  any  illegal  flows. 
So  a  procedure  is  effectively  parameterized  on  the 
security  classes  of  its  formal  parameters.  In  this 
sense,  it  is  polymorphic. 

For  example,  consider  the  procedure 

procedure  copy  (in  x  :  mt,  out  y  :  mt) 

begin 

y  :=  x 

end 

It  has  the  inferred  principal  type 

Va,  [3  with  a  C  f3  .  f3  proc(a,  [3  acc) 

where  a  and  [3  are  type  variables  such  that  a  cor¬ 
responds  to  the  security  class  of  x  and  [3  to  the 
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security  class  of  y.  The  principal  type  succintly 
conveys  how  the  procedure  can  be  securely  called. 
Any  call  can  be  executed  securely  providing  the 
arguments  of  the  call  have  security  classes  that, 
when  substituted  for  the  bound  variables  a  and  ft 
of  the  type,  satisfy  the  constraint  a  C  ft.  The  call 
itself  will  have  type  ft  and.  For  instance,  copy  has 
type  L  proc (L,  L  acc)  and  therefore  can  be  called 
to  copy  from  low  to  low,  with  the  call  itself  being 
regarded  as  a  low  command  of  type  L  and.  It  also 
has  type  H  proc(T,  H  acc),  so  it  can  be  called  to 
copy  from  low  to  high.  But  it  cannot  be  called  to 
copy  from  high  to  low  because  H  ft-  L. 

Notice  that  in  a  call  to  copy ,  type  variables  a 
and  ft  can  be  specialized  respectively  to  any  se¬ 
curity  classes  T\  and  To  as  long  as  the  subtype 
constraint  T\  ft  to  is  satisfied.  The  constraint,  in 
Denning’s  model,  translates  into  T\  — *■  To,  which 
is  precisely  condition  (&').  However,  in  the  secure 
flow  type  system,  the  constraint  is  inferred  auto¬ 
matically  as  a  consequence  of  typing  the  assign¬ 
ment  y  :=  x  by  rule  (1).  Denning's  approach  to 
polymorphism  effectively  limits  all  typings  of  pro¬ 
cedures  to  at  most  one  subtype  constraint,  namely 
the  constraint  corresponding  to  flow  condition  (If). 
This  greatly  limits  the  kind  of  polymorphic  proce¬ 
dures  one  can  write.  In  general,  a  procedure  can 
induce  multiple  subtype  constraints,  depending  on 
its  definition. 

It  might  appear  that  the  number  of  subtype  con¬ 
straints  in  a  principal  type  would  grow  too  quickly, 
in  the  size  of  the  program,  to  be  useful  in  prac¬ 
tice.  After  all,  there  are  programs  in  the  context 
of  traditional  subtyping  that  require  the  number  of 
constraints  in  their  principal  types  to  grow  at  least 
linearly  in  program  size  [9] .  Obviously,  the  utility 
of  a  type  inference  algorithm  that  produces  prin¬ 
cipal  types  with  this  many  constraints  is  severely 
limited.  However,  our  experience  has  been  that 
this  kind  of  growth  is  not  an  issue  for  secure  flow 
typing  in  practice:;.  An  inferred  principal  type  for 
a  program  is  typically  much  smaller  than  the  pro¬ 
gram  itself  due  to  type  simplification  [13].  Princi¬ 
pal  types  are  relatively  insensitive  to  program  size. 

For  instance,  consider  a  new  version  of  proce¬ 
dure  copy.  The  original  version  has  an  explicit 
flow  from  x  to  y.  Suppose  we  accomplish  the  same 


xO  aO  bO 


a2  - -  a4  b2  + -  b4 - -  b8 


a7  a8  b7 


Figure  1:  Accessibility  graph  for  new  copy 

effect  through  an  implicit  flow  instead.  This  can 
be  achieved  as  follows: 

procedure  copy) in  x  :  mi,  out  y  :  mi) 
var  a  :=  x 
var  b  :=  0 

begin 

while  a  >  0  do 

a  :=  a  —  1; 
b  :=  b+  1 

od; 

y  :=b 

end 

The  new  version  has  the  same  inferred  principal 
type  as  the  original  version  even  though  its  defini¬ 
tion  is  quite  different. 

Contrast  this  insensitivity  with  that  of  calculat¬ 
ing  an  accessibility  graph  for  the  program  as  de¬ 
scribed  in  [2] .  The  graph  calculated  for  the  original 
version  of  copy  has  only  the  single  edge  (#0,2/1), 
conveying  there  is  a  flow  from  x  at  entry  point 
Po  to  y  at  point  pi .  These  program  points  arise 
from  the  procedure  body  expressed  with  explicit 
program  points,  as  in  (pipy  :=  x);  there  is  also  a 
distinguished  point,  p o,  which  represents  the  entry 
point  of  the  procedure. 

Now  compare  this  simple  graph  with  the  graph 
in  Figure  1,  which  is  obtained  from  the  new  version 
of  copy.  The  new  graph  is  constructed  from  copy 
with  explicit  program  points  introduced  as  follows: 
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procedure  copy  (in  x  :  int,  out  y  :  int) 
var  a 
var  b  :=  0 
(Pi,  (P2,  a  :  =  x); 

(p3,  (p4,  while  a  >  0  do 

(P5,  (Pe,  a  :=  a  -  1); 

(P7,  b  :=b+  1) 

) 

od); 

(p8,  y  ■■=  b) 

) 

) 

The  constructed  graph  has  grown  in  size  propor¬ 
tional  to  the  number  of  program  points  (there  are 
now  9  such  points).  Notice  that  there  is  a  path 
from  *0  to  t/8  confirming  the  implicit  flow  from  x 
at  point  po  to  y  at  point  pg  in  the  program.  How¬ 
ever,  the  graph  does  not  tell  us  how  copy  can  be 
called  securely,  only  that  there  is  a  flow  from  x  to 
y.  For  these  reasons,  accessibility  graphs  are  un¬ 
suitable  as  user-level  specifications  of  a  procedure’s 
information  flow  properties.  Moreover,  one  can  see 
that  the  focus  of  this  approach  is  on  identifying 
flows  among  instances  of  program  variables.  This 
leads  to  other  problems  that  do  not  arise  with  se¬ 
cure  flow  typing.  For  example,  pointers  and  alias¬ 
ing  of  locations  complicate  graph  construction,  re¬ 
quiring  some  form  of  pointer  aliasing  analysis. 

As  a  final  example,  consider  the  library  decryp¬ 
tion  procedure  in  Figure  2,  taken  from  [2].  The 
encrypted  character  array  cipher  is  decrypted  us¬ 
ing  key  and  stored  in  clear.  We  assume  that  the 
decryption  is  done  by  D  and  that  the  cost  of  doing 
the  decryption  is  stored  in  variable  charge. 

The  principal  type  inferred  for  decrypt  is 

V  a,  13,17,  7 

with  (3  C  to,  (3  C  a,  j  C  (3. 

(3  proc(iz,  7  arr,  v  arr,  a  var) 

The  type  has  three  subtype  constraints  that  gov¬ 
ern  how  decrypt  can  be  used  securely.  Any  call  of 
the  procedure  can  be  executed  securely  provided 
the  arguments  of  the  call  have  security  classes  that 
satisfy  all  the  constraints.  The  call  itself  will  have 
type  (3  cmd.  For  instance,  the  substitution 

(3  =  L,  17  =  H,  7  =  a  =  L 


procedure  decrypt( in  key  :  int, 

inout  cipher,  clear  :  array  of  char, 
inout  charge  :  mi) 

var  i  :=  0 

var  unit  :=  unit  rate  constant 

begin 

charge  :=  unit ; 
while  ctpher[i\  >  0  do 

if  encrypted (ctpher[i\)  then 
charge  :=  charge  +  2  *  unit ; 
clear[i\  :=  D(cipher[i\,  key) 

else 

charge  :=  charge  +  unit ; 
clear[i\  :=  ctpher[i\ 

fi; 

i  :=  i  +  1 

od 

end 

Figure  2:  The  library  decryption  procedure 

satisfies  the  constraints,  so  decrypt  can  be  called 
as  a  procedure  with  type 

L  proc (H,  L  arr,  H  arr,  L  var) 

and  the  call  will  have  type  L  cmd.  The  call  cannot, 
however,  be  typed  as  H  cmd  unless  the  argument 
corresponding  to  charge  is  high. 

Another  very  useful  facet  of  type  inference  in 
this  setting  is  its  ability  to  reveal  suspicious  code 
through  changes  in  principal  types.  For  example, 
if  we  change  the  expression 

charge  :=  charge  +  2  *  unit ; 

in  procedure  decrypt  to  the  expression 

charge  :=  charge  +  key  +  2  *  unit ; 

in  an  attempt  to  deduce  the  key  from  the  output 
charge,  then  the  principal  type  of  decrypt  becomes 

V  a,  (3,8, 17,  7 

with  (3  C  17,  (3  C  a,  7  C  (3,  8  C  17,  8  C  a. 

(3  proc((5,  7  arr,  v  arr,  a  var) 

Notice  the  two  additional  subtype  constraints  8  C 
17  and  8  C  a.  The  former  says  that  the  security 
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level  of  the  clear  array  must  be  at  least  that  of  the 
input  key.  This  constraint  stems  from  the  assign¬ 
ment  to  clear  involving  a  call  to  the  decryption 
procedure  D  with  the  key  as  an  argument.  It  did 
indeed  arise  for  the  original  version  of  decrypt  as 
well,  but  it  was  eliminated  through  type  simplifi¬ 
cation;  6  was  replaced  by  v,  giving  v  C  v  which 
was  deleted.  The  latter  constraint,  on  the  other 
hand,  is  new.  It  says  that  the  security  level  of  the 
charge  parameter  must  be  at  least  that  of  the  in¬ 
put  key.  So  now  any  procedure  call  with  a  high 
key  will  no  longer  be  well  typed  unless  the  charge 
parameter  is  also  high.  Such  a  restriction  would 
likely  be  unacceptable,  but  the  point  here  is  that 
type  inference  clearly  reveals  it. 

4  Discussion 

As  Denning  pointed  out,  the  secure  flow  problem 
for  a  typical  programming  language  is  undecidable 
[8].  Consequently,  any  sound  and  recursive  logic 
for  proving  that  programs  have  no  secure  flow  vi¬ 
olations  is  necessarily  incomplete.  This  is  a  com¬ 
mon  tradeoff  for  the  soundness  and  decidability  of 
a  logical  system.  So  like  Denning’s  certification, 
the  type  system  is  incomplete.  This  means  that 
the  type  system  may  rule  out  some  secure  pro¬ 
grams.  Although  more  experience  is  needed,  the 
type  system  has  been  designed  to  reduce  the  num¬ 
ber  of  false  positives  [15]. 

The  utility  of  the  type  system  rests  on  the 
proper  classification  of  information.  Sometimes  an 
algorithm  will  produce  sensitive  data  from  inputs 
that  are  not  considered  sensitive.  Examples  range 
from  functions  that  generate  cryptographic  keys 
to  signal  processing  algorithms  designed  to  extract 
target  signatures  from  background  noise.  Perhaps 
neither  the  inputs  nor  the  arithmetic  operations 
used  in  these  algorithms  would,  separately,  be  con¬ 
sidered  sensitive.  But  they  may  be  used  to  calcu¬ 
late  sensitive  data.  The  type  system  will  not  detect 
that  such  data  are  actually  sensitive.  However,  the 
algorithm  can  be  packaged  as  a  procedure  whose 
type  can  be  asserted  to  reflect  the  different  secu¬ 
rity  levels  of  the  inputs  and  outputs.  Then  the 
type  system  can  ensure  that  it  is  called  securely. 


We  envision  secure  flow  typing  being  used 
within  Web  browsers,  specifically,  within  Java- 
compatible  browsers.  One  approach  being  inves¬ 
tigated  is  to  incorporate  it  into  the  Class  Loader 
for  Java  applets.  A  Class  Loader  could  perform 
secure  flow  typing  on  applet  bytecodes  and  sub¬ 
sume  the  level  of  type  checking  currently  done  on 
instructions  of  the  virtual  machine.  Such  typing 
would  ensure  secrecy  and  integrity  of  downloaded 
Java  applets.  In  the  case  of  integrity,  for  instance, 
one  can  imagine  financial  centers  serving  applets 
to  users  that  perform,  say,  financial  transactions. 
Some  applet  may  need  to  make  an  entry  into  a  fi¬ 
nancial  audit  trail  and  the  integrity  of  the  audit 
trail  must  be  assured.  Secure  flow  typing  could 
be  used  to  certify  that  an  applet  does  not  corrupt 
the  audit  trail  with  low  integrity  information  of  a 
transaction. 


5  Summary 

Approaches  to  the  static  analysis  of  code  for  se¬ 
cure  information  flow  have  had  little  impact  in 
practice  so  far.  This  paper  has  described  an  al¬ 
ternative  static  analysis  that  we  have  argued  is  an 
improvement  over  these  other  approaches.  Secure 
flow  analysis  is  characterized  as  a  type  inference 
problem.  Procedures  that  have  no  illegal  flows  are 
given  principal  types  that  convey  how  they  can  be 
called  securely  in  different  contexts.  These  types 
can  serve  as  specifications  for  the  secure  flow  prop¬ 
erties  of  programs.  The  role  of  secure  flow  typ¬ 
ing  in  Web  programming,  like  that  encouraged  by 
Java,  needs  further  investigation.  However,  it  is 
clear  that  such  type  inference  can  provide  a  finer 
level  of  security  for  clients  than  is  currently  avail¬ 
able  in  certain  Web  browsers. 
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